跳到主要内容

对于移动目标的一种偏见：数据集成（A Biased Take on a Moving Target: Data Integration）

由 Michael Stonebraker 介绍

被选中的读物​

这章没有被选中的读物

我将围绕数据继承的两大主题的相关历史，来展开这篇文章。站在我的立场来说，这一话题起始于1990年代，当时的主要的零售商们，将他们的销售数据，整合进入到数据仓库之中。而想要实现这个目标，他们就需要从商店内部的销售系统当中提取对应的数据，并将其转换到预定义的通用表示之中（请将通用表达视作为全局的模式），并在这个基础之上，将它们存储到数据仓库之中。数据仓库之中，存储着数年的历史销售数据，并且能够被组织当中的买家，应用于库存的轮换之中。换而言之，买家会发现宠物石已然“出局”，而属于芭比娃娃的时代“到来了”。而基于这个认识，他们将会把芭比娃娃的工厂与一则庞大的订单加以绑定，并将宠物石移除出去，并将其打折销售以便加速摆脱他们（避免更大的亏本，译者注）。一个经典的零售用的数据仓库，通过在每一年，作出更好的进货决策与作出股票轮换的决策，进而完成对自己使用成本的买单。而到了1990年代的晚期与2000年代的早期，因为基本上所有的企业都在效仿零售商的行为，将面向用户的数据存储于数据仓库之中，因此出现了规模庞大的“堆积”现象。

就此，一个为将数据加载进入数据仓库提供支撑的新行业就此诞生，它被称为提取、转换、加载（Extract, Transform, Load, 合称为 ETL）系统。基本的工作方法论在于：

  1. 在一切工作展开之前，设立一个全局的模式
  2. 将负责编码的软件设计人员派往每一个数据产生的来源，进而帮助他们找出提取数据的方法。而从历史上面看，编写这种类型的“连接器”，因为数据格式晦涩难懂，因此它往往意味着极其繁重的工作。我们真诚希望在未来伴随着更多的开源与标准化的数据格式的诞生，这项（编写连接器的）工作能够不再是那么棘手的事情
  3. 令程序员编写转换用的应用程序，这往往依托一门脚本语言，并且伴随着许多必要的清理用的例程
  4. 让程序员编写一个脚本，将数据正式加载进入到数据仓库之中

而一件显然的事情在于，因为三个巨大的问题，这个方法论可能会拓展到十几个数据源上面去：

  1. 首先，我们需要设立一个全局的模式。大约在这个时候，这种压力将会促进许多企业为所有自己将会面对到的对象设立一个企业范围内的模式。而一个工作团队将会接手这项工作，并且在此投入数年的时间。而在这个阶段终止之后，这项投入的结果就是，推进大约两年之后，宣告失败。因此，为一个泛泛的领域事先就构建好全局的模式，是一件相当困难的事情。而这也限制了数据仓库的合理使用范围。
  2. 中间涉及到的体力劳动过于繁重。它需要一名身经百战的程序员，为每一个数据源编写对应方法当中的绝大多数步骤。
  3. 数据的集成工作与清理工作，基本上非常困难。在1990年代，典型的数据仓库项目，往往能够超出原先估计时间与预计成本的两倍以上。这个问题诞生的核心就在于，项目的规划人员低估了数据集成这项工作的难度。而这主要又可以划分为两个巨大的问题。首先，数据本身是脏数据。经验法则告诉我们，你的数据当中，大约10%并不正确。而这一结论产生的原因来自于，（不正确的）工作人员与产品的昵称，过时的供应商的对应地址，以及不正确的年龄等情况。而第二点在于，去除重复的数据记录，是一件非常困难的事情。因为我们必须决定，Mike Stonebraker 和 M.R.Stonebraker 是相同的数据记录主体，还是不同的数据记录主体。而同样具有类似挑战性的情况在于位于同一地址的两家餐厅，他们可能都位于美食广场，且其中一家餐厅可能在某个单独的位置取代了另外一家餐厅的存在，或者，这根本就是一条数据记录错误。然而，在这种情况下，发掘这条记录背后的真相的成本，往往是如此的昂贵。

不过，尽管存在这些方面的问题，数据仓库在面向用户的数据应用方面，依旧是取得了相当巨大的成功，很多主要的企业已经开始应用这方面的技术。在这种使用的案例之下，构建复合数据的痛苦，可以通过做出更好的商业决策，来加以替代（权衡利弊，鱼与熊掌不可兼得，译者注）。我几乎从未听到过企业方面的人士抱怨数据仓库的运营成本。相对的，我听到的是业务的分析人员，希望尽力把握到更多的数据源，而无论这些数据源来自于互联网的公共数据，还是来自于其它的企业方面的数据。例如，大型企业大约只会拥有 5000 个操作数据存储的用例，而这些用例之中，只有少部分位于数据仓库之中。

据个简单的例子，在不久之前，我拜访了一家大型的啤酒制造商。他们根据品牌，经销商，销售时间段等情况，设立了为销售数据提供支持用的数据仓库。我就此，请教分析师们，人们普遍预测，厄尔尼诺现象将会在那一年的动态发生，而西海岸将会潮湿甚于以往，同时东北部的天气将会更加温暖。由此，提出一个疑问，啤酒的销售情况，是否就与这温度，或者是降水量有关。而他们的回复在于：“我们非常希望我们能够回答这个问题，然而天气的数据，并没有存储于我们的仓库之中”。而如果我们使用 ETL 系统这项技术的话，我们就很难支持数据源的自主扩充。

而再将视野放眼到2000年代，当时的新时髦话就是“主动数据管理”（master data management, MDM）。而MDM背后对应的理念就在于，将重要的数据主体（比如，顾客，雇员，销售人员，采购的人员，供应商等）的企业代表对象标准化。在这个基础上，为每一种对应的实体类型，仔细构建出对应的主数据集合来，并且让企业当中的每一个人员都使用这个主数据集合。这在一些时候，被称呼为“金唱片”（golden records）。实际上，原先的ETL供应商们现在就在销售MDM，并将其当作为一种更为广泛的产品。而在我看来，MDM被过度炒作了。

请允许我从“谁可以带头违反标准”这个话题展开论述，当然，这个带头人不可能是我。不过，MDM 存在如下的问题，我将会通过一些小的片段，来加以诠释。

在15年以前，当时我尚且在为 Informix 工作，当时的新任 CEO 在一次早期的员工会议上面，询问人力资源副总裁“我们拥有多少员工”，然而在下一周，她给出的回复是“我既不知道，感觉也找不出找出答案的办法”。Informix 在58个国家开展对应的业务，而在每一个国家，都有着他们对应的劳动法，以及对于雇员的定义。而对于雇员而言，不存在对应的“黄金记录”。因此，想要回答CEO抛出来的这个问题，唯一的办法就是，对这58个数据源展开数据集成，解决语义问题。而想要得到58个对应国家的管理人员的同意，无疑构成了一项挑战，而实际上 Informix 甚至并不是对于所有的组织，都掌握了对应的管理权限，这一事实令这项工作的开展更加障碍重重。新任的CEO很快就意识到了，想要完成这项工作，根本就是徒劳无功。

那么，为什么一家企业将会允许这项情况发生呢？答案非常简单：为了业务的敏捷性。Informix 会定期设立在各个国家设立对应的业务，同时希望销售团队快速组建起来，并且运行起来。而他们也会不可避免地要为对应的国家雇佣一名总经理，同时告诉他“请尽快把工作落地”。在某些时候，他将会是一名分销商，或者是一个独立的主体。如果他们说，“这就是你需要遵循的MDM黄金记录”，那么这位总经理/分销商就需要花费数个月的时间，以便于将他自身的需要，同MDM系统衔接起来。换而言之，在这里 MDM 站在了业务敏捷性的对立面。而显而易见的事情在于，每一家企业都需要在标准性和敏捷性之间，取得一个平衡。

而第二个小插曲，则牵涉到一家大型的制造企业。处于业务敏捷性的原因，他们被划分为一个个的业务单元。而每一个商业主体，都有着自己对应的用以指导业务部门与外部供应商打交道的条款与条件用的采购系统。这些系统的总量，大约是300多个。而维护这些系统的投资，其回报相当明显。毕竟，要维护的代码会相对少一些，而且每一家企业都可以获得比每一个单独的业务单元更好的合并条款。那么，究竟为什么会存在有这样多的采购系统呢？原因在于，这一家企业的发展，很大程度上要归功于并购。而每一次并购，都带来了新的商业组成单元，以及他们所附带的数据系统，商业合同等。而将这些数据系统整合到总部的IT基础设施，在一般情况下，通常是不明智的。简单来说，收购让MDM失灵了。

那么，究竟数据集成（或者数据存储工作）需要些什么呢？它往往包含如下的一些步骤：

  1. 数据的输入；我们必须找到并且捕获号数据源；这就需要我们对于存储用的所有数据结构，展开解析的工作；
  2. 数据的转换；比如，欧元对于美元的转换工作；或者机场代码到城市名称的转换工作；
  3. 数据的清理；我们必须找出并且纠正数据的错误；
  4. 模式的集成；你的工资就是我的薪水；
  5. 数据的整合（数据的去重）；Mike Stonebraker 与 M.R.Stonebraker 必须被整合成为一条单独的记录。

ETL 供应商们展开这些工作的成本高昂，同时其拓展性也相当低。而MDM供应商也面临着类似的处境。因此，还有一个巨大的未满足的需求。也就是大规模的数据管理是“坐在角落里面的800磅重的大猩猩”。所以，这个领域的研究挑战，究竟是什么？

让我们一步步地展开剖析。

数据的输入仅仅就是一个对数据源展开解析的问题。而其它的很多人已经编写了这样的“数据连接器”，他们一般而言构建成本相当高昂。而一个对应的有趣的挑战，就是半自动生成连接器。

而数据的转换得到了广泛的研究，这主要发生于过去的十年。[^130], [^54]，就研究了用于指定数据转换的脚本/可视化工具。Data Wrangler[^94]则似乎就是这一领域当中的最新的技术，我们非常鼓励感兴趣的读者去加以阅读。而除此之外，还有许多的商业产品，提供了收费的转换服务（比如，由地址到(lat, long)，或者由公司到规范公司名的转换等）。除此之外，我们可以在[^4]中找到从公共互联网寻找感兴趣的转换服务的有关工作的报道。

而数据清理技术，已经经由多种技术展开了研究的工作。[^41]应用功能相关性发现数据中的错误，并建议展开自动修复的工作。而异常值的检测（可能与错误相互对应）已经在许多的情况下面，展开了研究[^87]。[^162], [^158]则是应用于发现数据中的有趣模式的查询系统。这些模式可能就与数据的错误相互对应。[^148]则研究了众包与专家专用包的使用，而只要它们识别出错误，它们就可以想办法纠正对应的错误。最后，许多种类的商业服务都可以对常见的诸如个人地址与日期之类的数据错误展开清理。站在我的立场来说，数据清理的研究，必须同现实生活的数据相互结合。而发现那些被注入到明智的干净数据中的错误这种做法

已经使用多种技术对数据清理进行了研究。[41]应用功能相关性来发现错误数据并建议自动修复。异常值检测（可能对应于错误）已经在许多情况下进行了研究[87]。[162158]是用于发现数据中的有趣模式的查询系统。这样的模式可能对应于错误。[148]研究了众包和专家包的使用，一旦发现错误，就可以纠正错误。最后，还有各种商业服务可以清理常见的域，如个人地址和日期。在我看来，数据清理研究必须利用真实世界的数据。而发现那些注入到原本干净的数据中的故障这种办法，根本就不值得信任。而不幸的情况在于，现实数据的“脏”数据，往往非常难以获得。

模式的匹配，已经在过去的20年内，得到了广泛的研究。感兴趣的读者，可以查阅[^117], [^77], [^134]来了解这个领域的相关技术。

实体的合并，则是一个在高维空间（关于一个实体的所有属性的数量，通常为25个或者更多）中查找紧密连接在一起的数据记录的问题。而从实际来看，这是一个空间大小为25的聚类问题。它属于一个O(N^2)问题,因此在数据规模大的情况下，运行的时间将会相当长。因此，数据估算算法将会是我们在这里所选择的方法。技术方面的综述参考[^87]。

就我的观点而言，真正的问题是端到端的系统。数据的管理，需要所有的这些方面的步骤，而他们必须无缝集成，而企业范围的系统则必须大规模的执行管理的操作。一种有趣的端到端的方法就是 Data Tamer 系统[^148]。而从另外一个角度来看，数据的管理问题，也发生于部门的层面，个人的贡献者希望可以整合少数的数据源，而我们在上文当中提到的 Data Wrangler 系统似乎就是一种有趣的实现路径。因为存在一些商业公司同时支持这些系统，因此我们可以定期增强它们。

而我们非常希望下一版本的《数据库红皮书》能够收集好这一领域的开创性文章来，用以取代这一（存有私心的）行动呼吁。站在我的角度看，这是企业正在解决的最为重要的话题之一。我的一个警告是：“橡胶必须同道路相交”。如果你希望扎根于这个领域展开工作，你就必须在现实世界的企业的数据上面，测试你的想法。而手动构建数据，然后往里面写入错误，再发现他们，这种做法根本不值得信任。如果你存在这方面的想法，我建议你就设立一个端到端的系统。然后依托这种方式，你就可以确保你正在一个重要的问题，而不仅仅这是现实世界用户可能感兴趣或者根本不感兴趣的“边界问题”。

由 Joe Hellerstein 给出来的技术评论

2015年11月6日

我在大体上赞同 Mike 的评论，但是我希望在这个领域当中给出我自己的一点补充意见，这点与 Mike 提到的“部门级”问题相关。

基于各种组织的用户经验看，我们已然发现，数据的转换，越发转型为一项以用户为中心的人物，并且它就在很大程度上面，与用户的体验息息相关：为操作数据与交互式评估而设立的对外接口与编程语言。

而在如今的许多环境之中，正确的数据转换产出，就在很大程度上面，依赖于环境。想要了解数据是否为脏数据，你就必须掌握（如果正确的话）它应该是怎样的。而想要把数据转换得可用，你就需要了解到它的用途。即使就位于同一个组织当中，数据的应用问题以及它应当是什么样子，也根据具体人员与时间的不同而不同。加之 Mike 对于“黄金大师”这个概念的批评意见 --- 对于很多现代的使用案例而言，根本就意义不大，到了数据分析的环境当中，更是如此。

与之相对的，你需要为那些最了解数据和使用案例的人，构建出对应的工具来，促进他们用敏捷的、具备可探索性的方式来执行自身的数据分析工作与转换工作。计算机的科学家们，倾向于为技术用户 --- IT 专业人员与数据科学家 --- 进行对应的设计工作。但是，在绝大多数组织当中，了解数据与相关背景知识的用户，相较于IT部门，更加接近于“业务”。他们的技术水平往往较低。与其使用传统的 ETL 工具，它们往往会依赖 Excel 或者桌面数据库包当中的数据来展开工作，然而这两种工具都不太适合于评估数据的质量或者执行批量的数据转换。而对于大型的数据集合而言，他们使用“Microsoft Word 编写代码”：他们用自然语言描述他们想要的工作流程，并且等待IT部门产出对应的代码来，而到他们得到对应的产出的时候，他们会意识到这种做法不太适用。在这点，他们对于数据的需求会发生一定的变化。毫不奇怪的事情在于，人们经常断言，他们把50%～80%的时间花费在了“数据的准备”上面（作为注解，根据我个人的经验，现代的数据科学家倾向于通过 Python, R, SAS DataStep 的特殊脚本来对于数据进行甄别。同时这些脚本的代码质量与修订管理，松懈得往往让人吃惊。因此，伴随着时间的推移，他们甚至比老式的 ETL 用户更加糟糕！）

而商业用户使用图形工具，具有充分的理由：他们希望在数据转换的时候，了解对应的数据，并且做出评估，判断它是否越来越接近于采用对于他们的业务问题有用的形式。因此，在数据库的研究文章当中，对于无人职守的算法这种解决领域内的关键问题方面，依旧做得还是太少。而我相信，最为相关的解决方法，将会依托于接口，让人们可以更为直观地掌握他们数据的状态，同算法合作，并且更好的促进数据的使用。

而这也为创新提供了相当重大的机遇。数据转换是一个非常完美的培养器皿，它可以用于探索可视化和与数据交互的一般主题。这是一个可以把数据库、HCI、机器学习的思想结合到一起来的领域，它可以在算法和工作人员之间创建交互式的协作，使用数据解决实际的，独立于上下文的问题。而为了支持这件事情，我们就需要交互式的数据系统，它可以提供临时转换步骤结果的即时数据配置文件（各种数据的聚合），同时能够在用户之前实时推测，用以建议可能有用的多种数据替代转换。交互式数据分析的章节中的一些主题，就与此密切相关，特别是对于大的数据集合而言。近年来，我非常高兴能够在数据库的社区当中，看到更多的数据可视化与数据交互的工作；这是这项工作的一个相当好的应用领域。

参考​

[1] Z. Abedjan, J. Morcos, M. Gubanov, I. F. Ilyas, M. Stonebraker, P. Papotti, and M. Ouzzani. Dataxformer: Leveraging the web for semantic transformations. In CIDR, 2015.
[2] X. Chu, I. F. Ilyas, and P. Papotti. Holistic data cleaning: Putting violations into context. In ICDE, 2013.
[3] T. Dohzen, M. Pamuk, S.-W. Seong, J. Hammer, and M. Stonebraker. Data integration through transform reuse in the morpheus project. In SIGMOD, 2006.
[4] L. Haas, D. Kossmann, E. Wimmers, and J. Yang. Optimizing queries across diverse data sources. In VLDB, 1997.
[5] I. F. Ilyas and X. Chu. Trends in cleaning relational data: Consistency and deduplication. Foundations and Trends in Databases, 5(4):281–393, 2012.
[6] S. Kandel, A. Paepcke, J. Hellerstein, and J. Heer. Wrangler: Interactive visual specification of data transformation scripts. In CHI, 2011.
[7] R. J. Miller, M. A. Hern´andez, L. M. Haas, L.-L. Yan, C. H. Ho, R. Fagin, and L. Popa. The clio project: managing heterogeneity. SIGMOD Record, 30(1):78–83, 2001.
[8] V. Raman and J. M. Hellerstein. Potter’s wheel: An interactive data cleaning system. In VLDB, 2001.
[9] M. T. Roth and P. M. Schwarz. Don’t scrap it, wrap it! a wrapper architecture for legacy data sources. In VLDB, 1997.
[10] M. Stonebraker, D. Bruckner, I. F. Ilyas, G. Beskales, M. Cherniack, S. B. Zdonik, A. Pagan, and S. Xu. Data curation at scale: The data tamer system. In CIDR, 2013.
[11] M. Vartak, S. Madden, A. Parameswaran, and N. Polyzotis. Seedb: automatically generating query visualizations. In VLDB, 2014.
[12] E. Wu and S. Madden. Scorpion: Explaining away outliers in aggregate queries. In VLDB, 2013.